• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    SYSTEM CLINICAL MESSAGES, ROUTING OF 5 PROCESSORS SUMMARY OF MESSAGE SERVICE TO ROUTE LEGIBLE MEDIA BY COMPUTER, METHOD (500) CLINICAL MESSAGES AND ONE OR MORE PROCESSORS.A message service system (100) for routing clinical messages includes an event handler and a standardized protocol (105). The event handler (106) receives one or more incoming messages from one or more sources of the event (102). Event sources (102) include one or more items from the worklist. The event handler (106) still stores the worklist items in an event database (198) and generates and communicates outgoing messages for one or more worklist items in the event database (198) that need to be put into practice, as determined by one or more standards. The standardized protocol (105) is used to represent incoming and outgoing messages.
    公开号:BR112013017066A2
    申请号:R112013017066-2
    申请日:2011-12-21
    公开日:2020-11-24
    发明作者:Brian David Gross；Charles Lagor；David Warren Weiss；Monroe Wyatt Pattillo；Robert Duane Porterfield；Redvers Curtis Gosse
    申请人:Koninklijke Philips Electronics N.V.；
    IPC主号:
    专利说明:

    MESSAGE SERVICE SYSTEM FOR ROUTING CLINICAL MESSAGES, MEDIA LEGIBLE BY COMPUTER, METHOD (500) OF ROUTING OF CLINICAL MESSAGES AND ONE OR MORE
    PROCESSORS 5 DESCRIPTION This application relates, in general, to electronic communications. It finds particular application in the routing of alerts and messages to doctors, and will be described with articular reference to them. However, it should. 10 be understood that it also finds application among others. usage scenarios and is not necessarily limited to the application mentioned above. For example, it finds application in the manufacturing, firing, security and other industries. Clinical decision support applications 15 generally release generic alerts and / or alerts specific to terminal devices. For example, monitoring systems can generate alerts if a parameter reaches a certain threshold. However, a problem with alerts releasing generic alerts and / or alerts specific to 20 terminal devices is that these alerts fail to target specific doctors. “Failure to target specific doctors generally leads to alerts that reach doctors who are uninterested or never and reach a doctor who can act through the content of the alert. For example, a doctor may receive an alert that does not belong to his clinical role and / or his patient list.
    Other examples include a doctor who receives an alert while on vacation and / or unavailable or the alert being sent to a device the doctor is carrying
    3.0 that is physically turned off and / or outside the communication area. In addition, clinical decision support applications generally release alerts of their temporal relationship to a workflow and / or a patient's urgency. For example, an alert that indicates a need for a Pneumovax vaccine before hospital discharge is temporally premature at the time when the critically ill patient is arriving at an Intensive Care Unit (ICU). Addressing some of these issues, there are messaging systems that send alerts to devices and include business logic to take action when target devices fail to recognize alerts. .k However, these systems must typically be configured for each alert and / or user, which requires a lot of work, or are generic based on one or more of the event source, user role and notification device. In addition, they do not provide dynamic and / or complex business logic that is based on worklists for a particular user and / or patient. In addition, message service systems generally lead to less critical alerts that reach doctors than follow critical alerts, which takes up doctors' time. This can be confusing for doctors who provide service to more serious alerts. Also, messaging service systems typically wait a predetermined period of time for a doctor to accept an alert before alerting another doctor. This can increase the amount of time it takes to assist with less severe alerts, as these alerts are unlikely to be dismissed and escalation time should generally elapse.
    The present application provides a new and improved system and method for routing alerts and other messages to physicians, which overcomes the problems mentioned above and others. According to one aspect, a message service system for routing clinical messages is provided. The system includes an event handler and a standardized protocol. The event handler receives one or more incoming messages from one or more sources of the event. The messages include one or more items in the worklist. Event handler 5 still stores the worklist items in an event database and generates and communicates outgoing messages for one or more worklist items in the event database that need to be put into practice, depending on determined by one or more standards. The standardized protocol is% 10 used to represent incoming messages and outgoing messages. According to another aspect, a method of routing clinical messages is provided. One or more arrival messages in a standardized protocol are "15 received from one or more sources of the event. Arrival messages include one or more items from the worklist.
    B worklist items are stored in an event database and outgoing messages in the standardized protocol are generated and communicated to one or more worklist items 20 in the event database that need to be put into practice, as determined by one or more standards.
    According to another aspect, a method of self. description and communication of event information to an event handler is provided. An event notice is received and a message, using a standardized protocol, is generated. Messages include event information and one or more worklist items, represented using one or more standardized message properties. The items in the worklist specify who the message is addressed to and how the message should be routed by the event handler. According to another aspect, a work list is maintained per patient and per user. The worklist continues to track active alerts waiting for a response, active work items, and future or scheduled worklist items. The worklist allows system 5 to prioritize and redirect workflow based on the severity of incoming tasks or alerts for a given patient and user context.
    According to another aspect, a standardized protocol is used to establish the desired business logic 10 to route a message. This allows systems. who use this protocol establish a mechanism for an external system to pass the message with an end user context as part of the message and have the end user response passed back to the message service application, without the application needing to know nothing about the status or preferences of the end user.
    "An advantage of the present system and method is that it releases messages intelligently.
    Another advantage lies in the ability to route 20 alerts and / or messages to specific users and clinical functions.
    Another advantage is the ability to specify a next escalation step for an alert and / or message * within the alert and / or message.
    25 Another advantage lies in the ability to continue tracking the status of several pending alerts, work tasks and / or messages.
    Another advantage lies in the ability for a consolidated workflow to be supported by a multiplicity of different active systems for the user or patient. Another advantage lies in the ability to implement alert and / or messaging handling standards in a flexible manner, by processing messages compatible with self-describing protocols and by allowing specific business standards locally for systems that do not use the protocol.
    5 Another advantage is the ability to define complex escalation steps for alerts and / or messages.
    Another advantage lies in the ability to provide user recognition and response selection outside the natural application and have the responses passed back to the alert generation application.
    0 Another advantage lies in the ability to represent escalation steps for alerts and / or messages in a standardized manner. Another advantage is that the events are accepted - 15 and assistance is provided more quickly. Another advantage is that alarm fatigue and "distraction on the part of the team is reduced. Another advantage lies in the improved security.
    In addition, additional advantages of the present invention 20 will be appreciated by those skilled in the art, by reading and understanding the following detailed description. The invention can take shape in several components and component arrangements and in several stages and
    R layout of steps. The drawings are for illustrative purposes only and should not be construed as limiting the invention. FIGURE 1 provides an overview of a messaging service system, according to the aspects of the present disclosure; FIGURE 2 is a detailed block diagram of the message service system of FIGURE 1; FIGURE 3 is a block diagram of an event handler according to the aspects of the present disclosure; FIGURE 4 is an event message, according to the aspects of the present disclosure; FIGURE 5 is a block diagram for a method 5 of routing clinical messages; FIGURE 6 is a block diagram for a method of scaling worklist items based on target availability; e, FIGURE 7 is a block diagram for an open method.
    W 10 6 for self-description and communication of event information. k m
    J "Referring to FIGURE 1, in one embodiment, a 'message service system 100 includes one or more event source interfaces 104 for one or more event 102 sources, an event handler 106, a data interface 15 messaging service 108 for a messaging service 110 communicating with one or more event targets 112, and the like.
    "Event 102 sources generate event messages in response to clinical events and communicate event messages to event handler 106. Clinical events include 20 one or more among physiological events, such as low potassium detection in patients, notification of workflow, such as medication administration is due or has already expired, system events, such as a redundant array of independent disk talks (RAID) and the like.
    25 Event messages include information pertinent to the associated clinical event that a physician has found to be pertinent. For example, an event message generated in response to a blood pressure alert for a patient includes the patient's blood pressure. Each 30 of the event messages includes one or more worklist items and one or more from a unique event identifier, capabilities, event properties, time properties, source properties, target properties,
    recognition and similar properties, discussed in detail below. A worklist item is an action to be taken in response to an event. Event messages are communicated in one or more of a unilateral mode, bilateral mode 5 or similar. The messages communicated in the unilateral way do not need replies; while messages communicated in bilateral mode need responses. In certain achievements, responses can be used by event 102 sources to trigger actions at event 102 sources.
    In some embodiments, a distinction is made between unilateral event sources and bilateral event sources. One-sided event sources include the ability to send messages, but do not receive messages; and, bilateral event sources include the ability to send and receive messages, as a user response to an alert. Thus, bilateral event sources send unilateral messages and / or bilateral messages and receive messages; while, one-sided event sources send only one-sided messages. Additionally or alternatively, in some embodiments, a distinction must be made between adhered event sources and non-adhered event sources. Adhered event sources support a standardized protocol 105 understood by event handler 106, whereby they communicate directly with event handler 106. Non-adhered event sources, unlike adhered event sources, no longer support the protocol standardized 105 understood by event handler 106, with this, they communicate indirectly with event handler 106. The source interfaces of event 104 open the communications path between the non-adhered event sources and event handler 106. The interfaces event source
    8/40 104 receive messages sent from event sources not adhered to event handler 106, reformat messages to the standardized protocol 105 supported by event handler 106, and forward reformatted messages 5 to event handler 106. Also, interfaces event source 104 receive messages sent in standardized protocol 105 from event handler 106 to non-adhered event sources, reformat messages in a format accepted by non event sources. 10 adhered, and forward the reformatted messages to the non-adhered event sources. The event source interfaces 104 suitably include a single event source interface for all non-adhered event sources, an interface for or "15 incorporated into each non-adhered event source or the like.
    However, other configurations are considered. Per
    For example, an event source interface is used for each type of non-adhered event source (for example, a Philips Intellivue monitor "" MX800).
    20 The source interfaces of event 104 advantageously guarantee interoperability between the sources of e event 102 and the event handler 106. However, due to
    W the event source interfaces 104 do not need to be used by the attached event sources and the messages 25 sent in the standardized protocol 105 guarantee interoperability, the message service system 100 does not need to include the source interfaces of event 104 when the system message service 100 communicate only with subscribed event sources.
    30 Event handler 106 receives incoming messages, such as event messages and / or response messages, from event sources 102 and / or event targets 112, and communicates outgoing messages, such as escalation messages and / or messages event handler response, corresponding to target arrival messages and the like. Incoming event messages from event 102 sources properly output 5 escalation messages to event targets 112 of event messages, and incoming response messages from event targets 112 adequately produce response messages from event handlers 112 output to event 102 sources.
    W Upon receipt of an arrival message, 10 event handler 106 checks properly and, possibly, modifies the arrival message using one or more rules. A suitable standard includes a match criterion and a match action, which is performed if the match criterion is met. The "15 correspondence action includes, for example, modification of the incoming message. The correspondence action and / or the
    A matching criterion may take into account one or more of hospital policies, target settings, arrival message properties, status in service, 20 worklists, workflows, other events and the like. In addition, upon receipt of the arrival message, event handler 106 appropriately adds the arrival message, with any modifications that may have been made to it, to an event database 198 (see FIGURE 3). Each incoming message includes one or more items from the work list. Therefore, the arrival message is added to the event database 198 in order to add the worklist items to the database. An item in the worklist is an action to be taken in response to an event. For example, it is contemplated that an item on the work list specifies that an alert about a patient's hypoglycemia should be provided to the patient's doctor.
    To send outgoing messages, event handler 106 properly monitors worklist items in event database 198 to determine which, if any, of the worklist items need an outgoing message sent, determines when to send the message based on several factors, discussed below and, finally, sends the message to the target user. Suitably, this is accomplished using one or more standards, in which the matching criterion specifies the criterion for sending an outgoing message and the matching action specifies how to send the outgoing message. In one example, the standards include a standard that generates an outgoing message for worklist items that specify that an outgoing message is a priority to be sent immediately to a target user.
    As another example, the standards include a standard for generating an outgoing message for any items in the worklist that are due in the sense that an outgoing message was previously sent and no reply messages were received within an allowable amount of time. .
    The event handler 106 properly communicates with one or more of the event source interfaces 104, the message service interface 108, attached event sources, and sirnilars, using the standardized protocol 105, which provides a standardized format to represent all incoming and outgoing messages. The standardized format is defined by one or more properties. In certain realizations, properties are arranged in a hierarchical structure. The properties include one or more of a unique event identifier, capabilities, event properties, time and / or escalation properties, source properties, target properties, recognition properties, and the like.
    The unique event identifier uniquely identifies each event that a message refers to. The unique event identifier allows event handler 106 to determine an association between the items in the worklist in event database 198 and the message. For example, a bilateral event message leads to the addition of a worklist item to the 198 event database, where the worklist item is indexed using the event's unique event identifier. A reply message then identifies one. association to the worklist item using the unique event identifier.
    Capabilities include, for example, properties of an event source or an event target to handle "15 event messages or response messages, respectively. For example, capabilities include one or
    F more among support for unilateral event communications, support for bilateral event communications, maintenance of local worklists, ability to provide choices embedded in messages, support for visual messages, support for audio messages and the like. 6 The event properties, for example, identify one or more of the type of event that incites the generation of
    W message, the severity of the event, and the like. The 25 eyento types include one or more physiological events, protocol events, workflow events, system events, status events, equipment events and the like. Status events include events that describe the status of a patient, a system, or the like and include one or more 30 among unit status (eg, active orphan equipment), system status (eg, paperless recorder), system health (eg RAID failure), quality assurance status (eg patient compliance is below the 60% target), and the like. In addition, event types are used to group events. For example, a nurse separates protocol reminders (eg, lactate collection) from workflow reminders (eg, recording vital signs due) in a clinical information system. The severity of the event distinguishes high priority events (for example, suspected sepsis) from low priority events (for example, no sensor data for 30 minutes). Time and / or escalation properties include one or more of expiration time, escalation action, escalation time, delay properties, and the like for worklist items. Due date identifies the time that elapses before a worklist item is classified as due. The escalation action identifies how the worklist item is to be scaled. Escalation time identifies the time by which an associated worklist item needs to be escalated.
    The delay properties specify how long a response to a worklist item can be delayed. Delay properties include one or more of a property for no delay, which includes, for example, a pattern for bed alerts, a property for the length of delay, a property that defines the length of time that an alert needs to be persistent or active, in order to be processed by the system, and the like. The delay length ranges from 0 (implying no delay) to a predetermined number, such as 1440, with units of measure, such as seconds or minutes. In certain embodiments, the property for the delay extension subordinates the property to no delay, where a delay extension of 0 implies no delay. Additionally or alternatively, in certain embodiments, the delay properties are replaceable for predefined unit programming (ie delay for this exchange). Additionally or alternatively, in certain realizations, the delay is adjustable (when applicable) for each level of escalation. In addition or alternatively, in 5 certain realizations, for alerts subject to the standard based on time, the source of the event and / or event are not allowed to select a delay.
    The source properties typically include one or more of the source type, one or more source parameters, source location and the like. The source type identifies the source type of the event (eg Philips Intellivue monitor "" MX 800). The source parameters identify the type of parameters that triggered the event (eg blood pressure). The source location identifies where the source is located (for example, Cardiology unit II). Target properties typically include urri or more among target user, target function, target replica, target application, and the like. Target user specifies an individual to whom a message is targeted (for example, Dr. William Smith). The target role identifies the role of the target user (eg, available cardiologist or ICU nurse). The target replica identifies c) target user if the name is not known (eg , the patient's wife.) The target application includes being a device (for example, the Central station screen, Beeper 4434 etc.).
    Recognition properties properly capture the status of a worklist item. The recognition properties include one or more of an acknowledgment (for example, acknowledgment message from Dr. Smith), failure to send (for example, the message did not clearly send the query), failure to receive (for example, message returned from receiving service indicates failure),
    failure to acknowledge (for example, received on the terminal device, but no user acknowledged the alert), forced transition (for example, user requested transition), forced escalation (for example, µ user requested escalation), and
    5 similar.
    The standardized format divides incoming messages into one or more workflow items, each of which includes one or more properties.
    In certain embodiments, each workflow item is divided into one or more targets, each urri including one or more properties.
    In addition or alternatively, in certain embodiments, the standardized format includes a global section of one or more properties, where these properties are applied to each of the worklist items unless replaced by properties in the worklist items.
    Conforrne should be appreciated, in view of the previous discussion, the standardized protocol 105 allows event 102 sources to generate messages that specify the business logic for routing the messages.
    This in turn allows event 102 sources that use the standardized protocol 105 to establish a mechanism for event 106 to pass messages with an end user context as part of the message and have the end user response passed from back to the sources of event 102,
    without the event 102 sources needing to know anything about the end user's status or preferences.
    Message service interface 108 paves the way for communications between c) event handler 106 and message service 110 in circumstances when message service 110 fails to support the standardized protocol 105 supported by event handler 106. The service interface message 108 receives messages sent from event handler 106 to message service 110,
    reformats the messages in a communication protocol supported by message service 110, and forwards the re-formatted messages to message service 110. In addition, message service interface 108 receives messages 5 sent from message service 110 to the event handler 106, reformats messages to standardized protocol 105 supported by event handler 106, and forwards reformatted messages to event handler 106. When message service 110 supports standardized protocol 105 supported by event handler 106, the interface messaging service 108 may be unnecessary and / or removed from the messaging service system
    100.
    Message service 110 releases escalation messages from event handler 106 to event targets 112 and / or response messages for it to event handler 106. Still, in certain embodiments, message service 110 continues to track connected users to message service 110. As with the sources of event 102, message service 110 can be characterized as adhered or not adhered to, depending on whether it supports the standardized protocol 105 supported by event handler 106.
    Event targets 112 receive escalation messages from event handler 106 and, in some embodiments, generate and communicate response messages to event handler 106. Response messages, such as event messages, include one or more items from the job.
    Typically, to generate a response message, an event target presents an event message on a screen and / or prompts a user of the event target to provide a response to this via the screen and / or user input device. Interestingly, an escalation message for an event message can be sent to multiple event targets 112 once. User response and ability to respond may differ depending on the target of the event. Response messages include, for example, one or more of a unique event identifier, capabilities, event properties, time properties, source properties, target properties, recognition properties, and the like, as discussed above. As with event 102 sources, in some achievements, a distinction is made between unilateral event targets and bilateral event targets. Additionally or alternatively, in some embodiments, a distinction is made between adhered event targets and non-adhered event targets.
    With reference to FIGURE 2, the sources of event 102, in the illustrated embodiments, include one or more among monitors, such as a patient monitor 102a, clinical decision support applications, therapeutic devices, such as a therapeutic device 102b, clinical information systems , such as a clinical information system 102c, and the like. Communication units 118, 126, 134 from event 102 sources facilitate communication between event 102 sources and external devices, such as event handler 106 and / or event 104 source interfaces. Suitably, communication is performed by through one or more communication networks. Memories 115, 123, 131 from event 102 sources store patient and similar data and / or store executable instructions to perform one or more functions associated with event 102 sources. Screens 116, 124, 132 from event 102 sources allow that event 102 sources display data and / or messages for the benefit of users in one of the event 102 sources.
    User input devices 120, 128, 136 of event 102 sources allow users of event 102 sources to interact with associated event source 102 and / or respond to messages displayed on this screen. Processors and / or 5 controllers 114, 122, 130 from event 102 sources execute instructions stored in memories to perform the functions associated with event 102 sources.
    The source interfaces of event 104 in the illustrated embodiments include a first source interface of event 104a, which interfaces with multiple sources of the event. Communication units 138 of the event source interfaces 104 facilitate communication between an associated event source interface and an external device, such as event handler 106 and the event source
    102. Memories 142 of event source interfaces 104 store executable instructions to perform one or more of the functions associated with event source interfaces
    104. Processors and / or controllers 140 of the event source interfaces 104 execute instructions stored in the memories to carry out the functions associated with the event source interfaces 104. In some realizations 142, the data or messages are stored or buffered event 102 sources. In addition, each event 104 source interface adequately communicates through one or more communication networks. For example, in certain embodiments, an event source interface communicates with an unattached event source through a first communication network and event handler 106 through a second communication network, where the first communication network communication is different from the second communication network.
    Event handler 106 communicates with event targets 112 via message service interface 108 and / or message service 110, and communicates with event sources 102 directly or through the event source interface 104. In certain embodiments, the additional 106 event handler or 5 alternatively communicates with the 112 event targets directly.
    The message service interface 108 in the illustrated embodiments includes one or more of a communication unit 144, a processor and / or controller 146, a memory 148, and the like. Communication unit 144 facilitates communication between message service interface 108 and an external device, such as message service 110 and event handler 106. Memory 148 stores executable instructions for performing one or more of the functions associated with the interface message service 108. Processor and / or controller 146 executes instructions stored in memory 148 to perform functions associated with message service interface 108.
    The messaging service interface 108 appropriately communicates through one or more communication networks. For example, in certain embodiments, the message service interface 108 receives an escalation message from event handler 106 through a first communication network and forwards the escalation message to message service 110 through a second communication network. Communication.
    The message service 110, in the illustrated embodiment, includes one or more of a communication unit 150, a processor and / or 152, a memory 154, and the like. Communication unit 150 facilitates communication between message service 110 and one or more of message service interface 108, event handler 106, event targets 112, and the like. Appropriately, this is through one or more communication networks. Memory 154 stores executable instructions to perform one or more of the functions associated with message service 110. Processor and / or controller 152 executes instructions stored in memory 154 5 to perform functions associated with message service
    110. Event targets 112, in the illustrated embodiments, include one or more among portable devices, such as a cell phone 112a, therapeutic devices, such as a therapeutic device 112b, clinical information systems, such as a 112C clinical information system, monitors, such as a 112d patient monitor, clinical decision support applications, and the like. In addition, event targets 112 include one or more of one-sided event targets and / or one or more bilateral event targets. In addition, event targets include one or more adhered event targets and / or one or more non-adhered event targets, depending on whether or not the event targets support the standardized protocol 105.
    Communication units 160, 168, 176, 184 of event targets 112 facilitate communication between event targets 112 and external devices, such as event handler 106 and message service 110. Communications are properly conducted using one or more communication networks. Memories 157, 165, 173, 181 of the 112 event targets store one or more of the patient data, executable instructions to perform among one or more of the functions associated with the 112 event targets, and the like. Screens 158, 166, 174, 182 of event targets 112 allow event targets 112 to display data and / or messages for the benefit of users of event targets 112. User input devices 162, 170, 178, 186 of 112 event targets allow users of 112 event targets to interact with 112 event targets and / or respond to messages displayed on the screens. Processors and / or controllers 156, 164, 172, 180 of event 112 targets execute instructions stored in memories to perform functions associated with event 112 targets.
    The event handler 106 illustrated in FIGURE 3 includes one or more of the hospital's policy database 188, a target configuration database 190, an availability database 192, a standards database 194, an analyzer event handling protocol 196, event database 198, a design environment 202, an event handling standards executor 200, an audit log database 204, and the like. Although depicted with the event handler 106, the various databases, in some realizations, can be large central databases, institution or department that are accessed by the event handler 106.
    The hospital policy database 188 includes one or more settings that allow hospital administrators to specify the hospital policy. These settings, for example, let hospital administrators specify the minimum severity level for physiological events received from event 102 sources. Hospital policies are properly applied to incoming messages through one or more standards in the database standards 194. In certain embodiments, hospital policies include tough policies and soft policies. Tough policies are blocked from being modified and / or replaced by other settings, such as target settings; while, lightweight policies can be replaced with other settings, such as target settings.
    The target configuration database 190 includes one or more target specific configurations of an incoming message. For example, target configurations allow an individual to specify how they are contacted, such as via a cell phone only.
    5 These settings are properly applied, as long as they do not disagree with harsh hospital policies. Targets can include one or more of the event sources, event targets, individuals, functions, replicas, applications, devices, and the like. As with hospital policies, the target settings are appropriately applied to incoming messages via one or more rules in the 194 standards database. In certain embodiments, the target settings are linked to pre-set communication profiles, as a paging interface, central stations and customers linked to the unit. The availability database 192 tracks doctors that are currently available and typically includes one or more availability records that specify the doctors that are currently available. In certain achievements, the records. of availability include the roles of doctors. For example, the availability database 192 includes an availability record that specifies that Joe Smith is currently available for oncology. One or more of creation environment 202, message service 110, and the like can update availability records. The standards database 194 includes one or more standards for checking and / or modifying worklist items in incoming messages and / or in the event database 198. The standards for checking and / or modifying items on the worklist work on incoming messages are applied by the 196 event handling protocol analyzer, and the rules for checking and / or modifying worklist items in the event database 198 are applied by the event handling rules executor 200. As noted above, a standard appropriately includes a match criterion and a match action, where match 5 is performed if the match criterion is met. A matching action includes, for example, escalating a worklist item, modifying a worklist item in an incoming message and / or in the 198 event database, and the like. In certain embodiments, the standards include one or more standards for checking and / or modifying worklist items based on one or more specified targets. These standards use the availability database 192 to verify that an individual has specified as a target in a worklist item that is available or attainable, and, if not, to replace an individual specified as the target with one that is available. or achievable. In addition or alternatively, these standards use the availability database 192 to replace a target function specified as a target for a worklist item for an individual that is available. In both cases, the target is replaced according to one or more properties contained in the worklist item, hospital policies, target settings, and the like.
    Additionally or alternatively, in certain embodiments, the standards include one or more standards for checking and / or modifying worklist items based on worklists. A work list, for example, includes one or more tasks that need to be performed, such as the provision of a Pneumovax vaccine before the discharge of a critically ill patient. Worklists are comprised of several worklist items in an incoming message and / or in the 198 event database. Worklists are generally specific to one or more of the targets in a worklist item, as an event source or event target, patients, target roles, 5 target individuals, and the like. Among other things, it is contemplated that the rules that make use of worklists, in the illustrated realization, can increase and / or decrease the priority of worklist items based on worklists. This is accomplished by modifying the severity of a worklist item, the response time for a bilateral worklist item, and the like. For example, a standard could cause the 196 event handling protocol analyzer to increase a due time for a worklist item in an incoming message if its target becomes overwhelmed with one or more serious events.
    With this, in a sense, the worklist items associated with the worklists are dynamically classified, where this classification is adjusted using the standards. Additionally or alternatively, in certain embodiments, the standards include one or more standards for checking and / or modifying worklist items based on the source, such as event 102 sources or event targets
    112. For example, while an interface, such as event 104 source interfaces or message service interface 110, allows a target to analyze a message from an unattached source, the message may not yet have certain essential information. These standards add information and / or modify existing information from worklist items sent from non-adhered sources to fill any gaps that exist. Typically, these standards are only applied to the 196 event handling protocol analyzer.
    Additionally or alternatively, in certain embodiments, the standards include one or more standards for checking and / or modifying worklist items based on workflows. Workflows are suitably event-specific or target-specific, such as an event source, an event target, patients, target roles, target individuals, and the like. In some embodiments, workflows include state machines that define workflows. Also, in some realizations, norrnas delay outgoing messages for a worklist item until an associated workflow reaches a particular state.
    Additionally or alternatively, in certain embodiments, the standards include one or more standards for checking and / or modifying worklist items based on hospital policies, target settings, or the like.
    For example, the standards include one or more standards that increase the worklist items for a particular type of event, so the worklist items include a minimum severity level. As another example, the norms include one or more norms that increase the items in the work list directed at an individual target, in order to contact said individual using a means of communication preferred by the individual, such as through a cell phone. The standards database 194 also includes one or more standards for escalating worklist items in the 198 event database. These standards are applied by the 200 event handling standards executor. Escalation refers to sending an outgoing message to a target, whether it is an event target or an event source. For example, a standard specifies that an escalation message should be provided for a second target if a first target does not recognize an earlier provided escalation message, within 30 minutes. As another example, a standard specifies that an event handler response message must be communicated to an event source every 5 minutes, for a maximum of 60 minutes until the release is successful. The 196 event handling protocol analyzer processes incoming messages, including event messages and / or response messages, to extract one or more of the worklist items contained therein. Suitably, the event handling protocol analyzer 196 is employed to analyze incoming messages in the format of the standardized protocol 105. Therefore, several properties, including one or more among unique event identifiers, capabilities, event properties, target properties, properties of recognition, and the like, define the items in the work list. The 196 event handling protocol analyzer still checks and, when appropriate, updates the extracted worklist items. Items extracted from the worklist are checked and / or modified using one or more standards from the standards database 194, where standards are applied using one or more of hospital policies, target settings, arrival message properties, status in-service, worklists, workflows, other events, and the like. The extracted and possibly updated worklist items are then stored in the 198 event database.
    30 "The event handling protocol analyzer 196 includes one or more of a processor 206, a communication unit 208, a memory 210, and the like. The communication unit 208, in the illustrated embodiment, facilitates communication between the event analyzer event manipulation protocol 196 and other devices, such as event 104 source interfaces, event 102 sources, hospital policy database 188, and the like. Communications are properly carried out through one or more communication networks Memory 210 stores executable instructions to perform among one or more of the functions associated with the event handling protocol analyzer 196. Processor 206 executes the instructions stored in memory 210 to carry out the functions associated with the handling protocol analyzer of event 196.
    The event database 198 stores items extracted and possibly updated from the worklist.
    The worklist items are properly defined, according to the standardized protocol 105. Therefore, the event database 198 stores one or more of the unique event identifiers, capabilities, event properties, target properties, response properties and similar.
    The authoring environment 202 allows authorized users to modify one or more of the hospital's policies, target settings, and standards in the hospital's policy database 188, the target settings database 190, and the standards database 194 , respectively. In certain realizations, the creation environment 202 still allows authorized users to modify the availability records of the availability database 192. For example, the creation environment 202 allows an authorized user to change the roles of doctors. In other embodiments, data that interfaces with external programming systems is used to directly and automatically update the user role and the availability database 192. The creation environment 202 is also important for generating standards for updating messages non-adhered sources, such as non-adhered event sources, a non-adhered message service and non-adhered event targets. This allows messages from non-adhered sources to be handled in the same way as those from adhered event sources. In certain embodiments, the creation environment 202 is placed in a safe area or repeated locally from the production system, thus, the standards can be tested and verified without the interference of the active configuration and, then, activated to the production system.
    A desktop computer, a computer server, and the like suitably incorporate the 202 design environment.
    Both distributed and localized computer services are covered. The design environment 202 includes one or more of a screen 212, a processor and / or controller 214, a communication unit 216, a user interface device 218, a memory 220, and the like. The communication unit 216 facilitates the communication between the creation environment 202 and other components of the event handler 106, such as the hospital policy database 188, the target configuration database 190, the availability database 192 , and the standards database 194. Communications are properly carried out through one or more communication networks. Memory 220 stores executable instructions to perform among one or more of the functions associated with the creation environment 202. The processor and / or controller 214 executes instructions stored in memory 220 to perform the functions associated with the creation environment
    202. User input device 218 and screen 212 allow users of the design environment 202 to interact with the constituent database of the event handler
    106. The event 200 handling standards executor queries the event database 198 to determine whether there are items in the worklist that need to be put into practice using the standards in the standards database 194.
    A worklist item needs to be put in place if an outgoing message needs to be sent to it. For example, if a worklist item specifies that immediate targeting is required, the worklist needs to be put into practice. Suitably, the event handling standards executor 200 checks items on the worklist that need to be put into practice at regular intervals. However, other trigger events are contemplated. For example, in certain achievements, each worklist item is suitable for triggering, in its own timing, a check of the worklist item.
    When the event handling standards 200 executor identifies one or more worklist items that need to be put into practice, it checks the worklist items and generates an outgoing message for the worklist items in the standardized format 105, using one or more standards in the standards database 194. Outgoing messages include escalation messages and event handler response messages. These standards properly check and / or generate worklist items based on one or more of hospital policies, target settings, arrival message properties, status in service, worklists, workflows, other events, and similar. The output messages generated are then sent to the event target or event source specified by the worklist item depending on the source of the worklist items (ie, event message or response message). After an outgoing message is sent to a worklist item, the event handling standards 200 executor removes the worklist item from the event database 198 or updates it in the event database 198 to reflect that an outgoing message was sent.
    The worklist item is properly removed
    5 of the event database 198 when the tasks associated with it are completed, in order to maintain the event database 198 with only the pending items in the work list.
    A worklist item for a one-sided event message is properly completed when an escalation message is released to the event target, and a worklist item for a two-way event message is properly completed when a response message for the event message is released to the event source of the event message.
    Response messages are typically one-sided.
    The event handling standards executor 200 includes one or more of a 222 processor and / or controller,
    communication unit 224, memory 226, and the like.
    The communication unit 224 facilitates communication between the event handling standards executor 200 and other devices, such as a message service interface 108,
    event targets 112, the database of standards 194, and the like.
    Communications are suitably carried out through one or more communication networks.
    Memory 226 stores executable instructions to perform among one or more of the functions associated with the event handling standards executor 200. The processor and / or controller 222 executes instructions stored in memory 226 to perform functions associated with the event handling protocol analyzer. event 200. The audit log database 204 keeps a record of the steps taken by the event handling protocol analyzer 196 and the event handling rules 200 executor. Suitably, all steps are logged, but logging schemes more sophisticated are conceivable. Logging all steps allows authorized users to reconstruct previous event 5 messages that have been removed from the event database
    198.
    With reference to FIGURE 4, an example of an event message 400 generated, for example, by a patient monitor is illustrated. Event message 400 employs the standardized protocol 105, described above, and is targeted at multiple targets. For example, event message 400 is intended for users a and b, who must have acknowledged an escalation message at a severity level "4" within 30 seconds of release; otherwise, event message 400 is escalated for immediate notification at severity level "3" to user d. The 400 event message is still addressed to user f at a severity level of "3" only if the event persists for more than 2 minutes. User f would have to acknowledge the alert within 60 seconds, so as not to be notified again.
    With reference to FIGURE 5, a method 500 of routing clinical messages using the event handler 106 of FIGURE 1 is provided. A determination 502 is made as to whether an incoming message, be it an event message or a reply message, is present. If no incoming message is present, event database 198 is queried 512 and determination 514 is made as to whether an item in the worklist needs to be put into practice. If an incoming message is present, it is received 504 in the standard format 105. The items in the work list contained in the arrival message are extracted 506.
    The items extracted from the work list are checked and possibly modified 508 using one or more standards in the database of standards 194. These standards are based, for example, on one or more of the hospital's policies, target settings, properties of the event messages, status in service, worklists, workflows, 5 other events, and the like. The verified and possibly modified standards are then stored 510 in the event database 198. The event database 198 is queried 512 and a determination 514 is made as to whether an item in the worklist needs to be put into practice. .
    This determination is properly made using one or more standards in the standards database 194. If no worklist item is determined to need action, the determination of whether an incoming message is present 502 is repeated. Suitably, a delay is brought. If a worklist item is identified that needs action, the worklist item is checked for 516 against one or more standards in the standards database 194 and an outgoing message, either an escalation message or an event handler response message, 518 is generated and 520 is sent in standardized format 105 to a target user identified by the standards. The worklist item is then updated or deleted 522. Method 500 then starts again with determination 502.
    With reference to FIGURE 6, a method 600 of scaling worklist items based on target availability is provided. Method 600 is an embodiment of method 500 and is suitably performed by processors 206, 214, 222 of event handler 106.
    As will now be seen, method 600 advantageously allows worklist items for a location, device, or patient, such as a bed, to be serviced more quickly to prevent known alert loops from assisting worklist items. higher priority. In addition, the 600 method advantageously reduces alarm fatigue and distraction by targets, thereby improving overall safety. For easy discussion, method 600 is limited to a single item on the worklist.
    5 However, it should be appreciated that it is equally conceivable for a plurality of worklist items and event messages. Method 600 assumes that one or more of the databases 188, 190, 192, 194, 198, 204 of event 106 cooperate to define escalation sequences and their assignments to locations, devices, or patients of an institution that employs the event handler 106. Each escalation sequence includes one or more escalation levels and the escalation order advances through the escalation levels. For example, a location, device, or patient includes an escalation sequence that identifies a first escalation level for primary targets and a second escalation level for secondary targets, where escalation proceeds from the first escalation level to the second escalation level . Method 600 also assumes one or more of the databases 188, 190, 192, 194, 198, 204 of event handler 106 cooperate to define location, device or patient assignments for targets, such as users, groups, devices, and so on. onwards, and escalation level assignments for location, device, or patient assignments. For example, a first user is assigned to a patient's first escalation level, and a second user is assigned to a second patient escalation level. Declared differently, the first user is assigned primary responsibility for the patient, and the second user is assigned secondary responsibility for the patient.
    A 602 determination is made as to whether an event message, including a worklist item, for a location, device, or patient is present.
    If no event messages are present, a determination 5,610 is made as to whether escalation is necessary, as discussed below.
    Otherwise, the event message is received 604 from an event 102 source, such as a patient monitor, optionally in the standardized format.
    The location, device or patient is assigned an escalation sequence including a plurality of escalation levels, each escalation level including a target, such as a user, a device, an application, a group, and so on.
    As noted above, the escalation sequence and assignments are properly defined through the cooperation of one or more of the 188, 190, 192, 194, 198, 204 databases of event handler 106. The worklist item includes a current position within the escalation sequence.
    The current position is initially the first escalation level in the escalation sequence, but advances with escalation.
    After receiving 604 of the worklist item, it is optionally updated 606 (ie checked and modified) using one or more standards in the 194 standards database. These standards are, for example, based on one or more of hospital policies, target settings, event message properties, status in service, worklists, workflows,
    other items on the work list, and the like.
    For more details, attention is directed to the above discussion of event handler 106. The checked and possibly modified item in the worklist is then stored 608 in event database 198. Determination 610 is then made to a worklist item needs escalation (that is, an escalation message needs to be sent) when querying the event database 198 and checking the worklist item for one or more standards in the database in
    5 standards 194. For example, a standard can specify a first escalation message that must be sent immediately upon receipt of the worklist item, and another standard can specify a second escalation message that must be sent after a period predetermined amount of time elapses without receiving any acceptance and / or acknowledgment of the first escalation message.
    As another, a standard can specify that, if an escalation message previously sent to the worklist item is rejected by the target then the escalation is in order.
    Typically, the event database 198 is consulted periodically, but it is also contemplated that the event database 198 is consulted continuously or through the event of an event.
    In some embodiments, when the worklist item has to be escalated, a 612 determination is made as to whether a target of the first escalation level in the escalation sequence previously rejected a worklist item with a higher or equal priority level priority level of the worklist item to be scaled.
    Optionally, the previous rejection is limited to a rejection within a predetermined period of time from determination 612. It is contemplated that the predetermined period is specific to the target and, optionally, specified in the target configuration database 190. When that rejection has not been made and an escalation message for the worklist item has not been sent to the target, an escalation message is generated 614 and communicated 616 to the target of the first escalation level. Determination 610 of whether a worklist item is to be escalated is then repeated after determination 602 of whether a new event message is present to be made. 5 When it is determined that the worklist item should be escalated and, if applicable, rejection must be made, the event handler identifies 618 a next escalation level for the location, device, or patient.
    V This includes retrieving the escalation sequence for the 10 location, device, or patient corresponding to the event message, as well as the location, device, or patient assignments for the target assignments and escalation level for the location assignments, device, or patient, from one or more of the 188, 190, 192, "15 194, 198, 204 databases of event handler 106. Advantageously, when retrieving the assignments for each escalation, changes to the escalation sequences and / or targets assigned to escalation levels (for example, due to programming changes or switching changes) are taken into account.When an escalation sequence does not exist, a standard escalation sequence including at least one escalation level scaling level can be used.
    W may include, for example, supervisors or managers of the institution. 25 Beginning with the current position within the escalation sequence, the escalation levels of the retrieved escalation sequence are then stepped in order until the end of the escalation sequence is reached or an escalation level with a target that has already is not providing a service to a higher and / or equal priority worklist item is found. While scheduling the escalation sequence, the current position is updated. In some embodiments, the next escalation level includes at least one target that no longer serves a higher and / or equal priority worklist item and that no longer serves a worklist item that exceeds a predetermined priority limit. For example, 5 if a primary target is serving a serious but not life-threatening worklist item, and a life-threatening worklist item for the primary target is received, the received work can be escalated to a secondary target.
    A target is considered to be serving a worklist item when a message that accepts and / or recognizes the worklist item is received from the target. In addition, a target is considered to have completed the provision of service for a worklist item upon receipt of a message for that purpose and / or after a predetermined period of acceptance and / or recognition has elapsed. In some embodiments, the predetermined period is specific to the target and, optionally, specified in the target configuration database 190. Also, in some embodiments, a target is considered to have terminated the provision of services to a worklist item by receiving a message that indicates that the target wants to pass the worklist item to another target using the escalation procedure. For example, a primary target for a location, device, or patient receives a high priority worklist item for a location, device, or patient and fails to finish the low priority worklist item for another location, device , or patient for which he is the primary target. The low priority worklist item can be passed to a secondary target. Event handler 106 adequately tracks whether targets are providing service to worklist items by keeping records of them in one of the 188, 190, 192, 194, 198, 204 databases and / or memories 210, 226, 220 of event handler 106.
    When the end of the escalation sequence is reached, a standard escalation sequence can be employed. Otherwise, the worklist item is checked 620 for one or more standards in the standards database 194 and an escalation message for the worklist item is generated 622 and communicated 624 to the target
    T 10 marked with an event 112 target.
    . Suitably, the escalation message is sent in a standardized format. The worklist item is then deleted or updated 626 to reflect that the escalation message has been sent, and determination 602 is made as to whether new "15 event messages are present. In some embodiments, worklist items of lower priority to which the identified target is providing service are escalated in response to the identified target providing service to the worklist item. It is contemplated that this escalation may still need to receive a message from the identified target indicating that at least an identified target wishes to pass 0 items from the lower priority worklist to other targets using the escalation procedure.
    It is contemplated that the escalation may be for a target, such as a supervisor, chosen by the identified target.
    With some achievements, the priorities of items in the work list that are provided by the identified target are compared against a predetermined priority limit. Notably, these items in the work list 30 are of lower priority than the item received from the work list, due to the identified target not having otherwise received an escalation message for the work list item. In response to those worklist items that exceed the predetermined priority limit, the escalation message is also communicated to the escalation level targets after the next escalation level. For example, if an escalation message 5 was sent to a target for a serious but not critical worklist item, and a life-threatening worklist item was received by the target, an escalation message for the item from the life-threatening work list can be sent to the target, as well as to another target at the highest escalation level.
    Referring to FIGURE 7, a method 700 of self-describing and communicating event information to event handler 106 is provided. One of the event source interfaces 104 and / or the message service interface 108 properly performs method 700. Event information, such as an event warning or a user response to an event, is received 702 from, for example, one of the sources of event 102 and / or message service 110. A message is generated 704 using the standardized protocol 105. The message includes event information and one or more items in the worklist, represented using one or more standardized message properties. Worklist items specify who the message is directed to and how the message should be escalated by the event handler 106. The message is then communicated 706 to the event handler
    106. Each of the databases described here, such as the hospital policy database 188, appropriately includes a computer database, where the computer database is incorporated by a single computer, distributed over a plurality of computers, or the like. In addition, each of the databases adequately stores data in a structured manner, facilitating reactivation and access to that data. Also, as used herein, a memory includes one or more of a non-temporary, computer-readable medium; a magnetic disk or other magnetic storage medium; an optical disc or other optical storage medium; a random access memory (RAM), read-only memory (ROM), or other electronic memory device or chip or set of chips interoperably interconnected; an Internet server from which stored instructions can be retrieved via the Internet or a local area network; or so on. In addition, as used herein, a controlled urr includes one or more of a microprocessor, a microcontroller, a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), a programmable field gate matrix (FPGA) , and the like; a communication network includes one or more of the Internet, a local area network, a wide area network, a wireless network, a wired network, a cellular network, a data bus, such as USB and I2C, and the like; a user input device includes one or more of a mouse, keyboard, touchscreen, one or more buttons, one or more keys, one or more toggle levers, voice-driven interaction, and and a screen includes one or more of an LCD screen, an LED screen, a plasma screen, a projection screen, a touchscreen and the like.
    The teachings of the present disclosure can be implemented in any clinical IT infrastructure (both hospital and outpatient), where there are devices (for example, monitors) and information systems (for example, ICU information systems or information systems). healthcare) that generate alerts or reminders. In systems that are capable of exposing clinical worklists, the present disclosure can extract that information and consolidate and maintain it.
    In addition, the teachings of the present disclosure can be implemented outside of health care.
    For example, they can be used for use in hospitalization management, such as room service or food service. As another example, they can be used for use with event management from multiple overhead or overhead systems, where workflow consolidation across multiple systems is required.
    The invention has been described with reference to - 10 preferred embodiments. Modifications and - changes to other people may occur, by reading and understanding the previous detailed description. The invention is intended to be constructed as including all such modifications and changes, insofar as they are within the scope of the appended claims or their equivalents.
    权利要求:
    Claims (15)
    [1]
    1. MESSAGE SERVICE SYSTEM (100) FOR ROUTING CLINICAL MESSAGES, characterized in that said message service system (100) comprises: 5 an event handler (106) that:
    B receives one or more incoming messages, including one or more items from the work list, from one or more sources of the event (102); stores the worklist items in a database - 10 of event data (198); and, D generates and communicates outgoing messages for one or more items in the worklist in the event database (198) that need to be put into practice, as determined by one or more standards; and '15 a standardized protocol (105) for representing incoming and outgoing messages.
    W
    [2]
    2. MESSAGE SERVICE SYSTEM (100), according to claim I, characterized in that the event handler (106) checks and / or modifies the items of the work list of the incoming messages using one or more standards, where standards are based on one or more of 0 hospital policies, target settings,
    V arrival messages, status in service, worklists, and workflows.
    25
    [3]
    3. MESSAGE SERVICE SYSTEM (100), according to either of claims 1 or 2, characterized in that the event handler (106) determines the items in the worklist that need to be put into practice using one or more standards , where the standards include one or more 30 standards based on the worklists implicit in the event database (198) and / or workflows.
    [4]
    4. MESSAGE SERVICE SYSTEM (100), according to any one of claims 1 to 3, characterized in
    2/4 that the event handler (106) updates and / or deletes worklist items in the event database (198) for which outgoing messages have been generated and communicated.
    [5]
    5. MESSAGE SERVICE SYSTEM (100) according to any one of claims 1 to 4, characterized in that the incoming messages include properties that specify when the corresponding outgoing messages are to be sent.
    [6]
    6. MESSAGE SERVICE SYSTEM (100), according to any one of claims 1 to 5, characterized in that the event handler (106) is configured to: receive a worklist item for a location, device or patient arrival messages, where the location, device, or patient includes an escalation sequence of escalation levels, each escalation level including a target; determine whether the worklist item should be scaled using the standards; in response to determining the worklist item to be escalated, identify a next escalation level for the location, device, or patient, the next escalation level including only a target (s) that no longer provides service to items from the work list of higher and / or equal priority; and, generate and communicate an outgoing message for the worklist item to the identified target.
    [7]
    7. MESSAGE SERVICE SYSTEM (100), according to claim 6, characterized in that the next escalation level is identified by escalation along the escalation levels of the escalation sequence until a escalation level including a target that no longer provides service for items of the highest and / or equal priority work list is found.
    [8]
    8. LEGIBLE MEDIA BY COMPUTER, characterized by loading the software that controls one or more processors to perform the functionality of the event handler (106), as defined in any one of claims 1 to 7.
    [9]
    5 9. METHOD (500) OF ROUTING CLINICAL MESSAGES, the said method (500) being characterized by understanding: receiving (504) of one or more incoming messages in a standardized protocol (105) from one or more sources of the event (102), said arrival messages including one or more items from the work list; storage (510) of worklist items in an event database (198); and, generation (518) and communication (520) of outgoing messages in the standardized protocol (105) for one or more worklist items in the event database (198) that need to be put into practice, as determined by a or more standards.
    [10]
    10. METHOD (500), according to claim 9, characterized in that it additionally includes: checking and / or modifying (508) the items in the work list of incoming messages using one or more standards, in which the standards are based on one or more of hospital policies, target settings, arrival message properties, status in service, worklists and workflows
    [11]
    11. METHOD (500), according to one of claims 9 or 10, characterized in that the generation (518) of the outgoing messages uses one or more standards based on one or more of the hospital's policies, target configurations, properties of the arrival messages, status in service, worklists and workflows.
    [12]
    12. METHOD (500) according to any one of claims 9 to 11, characterized in that it additionally includes: receipt of a worklist item for a location, device or patient of incoming messages, in which the location, device , or patient includes an escalation sequence of escalation levels, each escalation level including a target; determining whether the worklist item should be scaled using the standards; 10 in response to determining the list item of ± work to be escalated, identifying a next escalation level for the location, device, or patient, the next escalation level including only target (s) that are no longer suitable for the items of the task list of priority "15 greater and / or equal; and, generation and communication of an outgoing message to
    V the worklist item to the identified target.
    [13]
    13. METHOD (500), according to claim 12, characterized in that the identification includes: 20 escalation along the escalation levels of the escalation sequence until a escalation level including a target that no longer provides for the items of the escalation list of W task of higher and / or equal priority to be found.
    [14]
    14. ONE OR MORE PROCESSORS, characterized in that 25 are pre-programmed to perform all steps of the method (500), as defined in any of claims 10 to 13.
    [15]
    15. LEGIBLE MEDIA BY COMPUTER, characterized by loading the software that controls one or more processors 30 to perform all the steps of the method (500), as defined in any one of claims 10 to 13.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112013017066A2|2020-11-24|message service system for routing clinical messages, computer readable medium, method | routing clinical messages and one or more processors
    US10827985B2|2020-11-10|Notification system of deviation from predefined conditions
    US8571884B2|2013-10-29|Healthcare communication and workflow management system and method
    US20200066401A1|2020-02-27|Method for facilitating communication, data access and workflow in a healthcare environment/facility
    US8527449B2|2013-09-03|Sepsis monitoring and control
    US7310607B2|2007-12-18|System for processing healthcare related event information for use in scheduling performance of tasks
    US10409957B2|2019-09-10|Real-time event communication and management system, method and computer program product
    US20110077965A1|2011-03-31|Processing event information of various sources
    JP2002342484A|2002-11-29|Method and system for identifying and anticipating adverse drug event
    NZ546843A|2007-09-28|System and process for facilitating the provision of health care
    US8736453B2|2014-05-27|Preemptive notification of patient fall risk condition
    US20090125328A1|2009-05-14|Method and System For Active Patient Management
    Srivastava et al.2019|Impact of patient-centred home telehealth programme on outcomes in heart failure
    KR101894188B1|2018-08-31|Alarm and report system for adverse events of clinical trials based on hospital medical record systems
    Turvey et al.2007|Telehealth screen for depression in a chronic illness care management program
    US20180181870A1|2018-06-28|Integrating flexible rule execution into a near real-time streaming environment
    Nunes‐Ferreira et al.2020|Non‐invasive telemonitoring improves outcomes in heart failure with reduced ejection fraction: a study in high‐risk patients
    US20160344808A1|2016-11-24|Device data synchronization
    US20190221319A1|2019-07-18|System and method for providing workflow-driven communications in an integrated system
    WO2020039752A1|2020-02-27|Information reporting device, information reporting method, and program
    KR102144540B1|2020-08-13|Method for operating connected personal health record service based on block chain for emergency
    US20200411198A1|2020-12-31|Falls risk management
    WO2021052884A1|2021-03-25|Clinical decision support scheduling and alerts
    US20160342670A1|2016-11-24|Device data synchronization
    同族专利:
    公开号 | 公开日
    RU2013136495A|2015-02-10|
    CN103380603A|2013-10-30|
    CN103380603B|2016-12-14|
    US20130275539A1|2013-10-17|
    JP2014507843A|2014-03-27|
    EP2661849A1|2013-11-13|
    JP5860901B2|2016-02-16|
    RU2605363C2|2016-12-20|
    EP2661849B1|2019-05-29|
    US9356888B2|2016-05-31|
    WO2012093307A1|2012-07-12|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US5319355A|1991-03-06|1994-06-07|Russek Linda G|Alarm for patient monitor and life support equipment system|
    JP4224136B2|1996-07-12|2009-02-12|ファーストオピニオンコーポレーション|Computerized medical diagnostic system using list-based processing|
    US6631363B1|1999-10-11|2003-10-07|I2 Technologies Us, Inc.|Rules-based notification system|
    US20010051890A1|2000-03-17|2001-12-13|Raleigh Burgess|Systems and methods for providing remote support via productivity centers|
    US20050143671A1|2003-12-31|2005-06-30|Ge Medical Systems Information Technologies, Inc.|Alarm notification system and device having voice communication capability|
    US7860583B2|2004-08-25|2010-12-28|Carefusion 303, Inc.|System and method for dynamically adjusting patient therapy|
    WO2006067725A2|2004-12-22|2006-06-29|Philips Intellectual Property & Standards Gmbh|Medical monitoring method and system|
    US7684548B1|2005-04-28|2010-03-23|Techradium, Inc.|Notification and response system with attendance tracking features|
    US20070180140A1|2005-12-03|2007-08-02|Welch James P|Physiological alarm notification system|
    US20090132580A1|2007-11-21|2009-05-21|General Electric Company|Systems and Methods for Creating and Viewing Clinical Protocols|
    KR20100039705A|2008-10-08|2010-04-16|삼성전자주식회사|Method and apparatus for managing patient|
    WO2010052624A1|2008-11-06|2010-05-14|Koninklijke Philips Electronics N.V.|Dynamic clinical worklist|
    EP2356602A1|2008-11-06|2011-08-17|Koninklijke Philips Electronics N.V.|Method and system for simultaneous guideline execution|
    US20110208540A1|2008-11-06|2011-08-25|Koninklijke Philips Electronics N.V.|Executable clinical guideline and guideline tool|
    US10217063B2|2008-12-31|2019-02-26|Teletracking Technologies, Inc.|System and method for clinical intelligent agents implementing an integrated intelligent monitoring and notification system|
    EP2795495B1|2011-12-21|2019-09-04|Koninklijke Philips N.V.|Method and system to predict physiologic and clinical status changes|US9123077B2|2003-10-07|2015-09-01|Hospira, Inc.|Medication management system|
    US8065161B2|2003-11-13|2011-11-22|Hospira, Inc.|System for maintaining drug information and communicating with medication delivery devices|
    CA2666509C|2006-10-16|2017-05-09|Hospira, Inc.|System and method for comparing and utilizing activity information and configuration information from multiple medical device management systems|
    US8271106B2|2009-04-17|2012-09-18|Hospira, Inc.|System and method for configuring a rule set for medical event management and responses|
    WO2013059615A1|2011-10-21|2013-04-25|Hospira, Inc.|Medical device update system|
    EP2929476A1|2012-12-04|2015-10-14|Koninklijke Philips N.V.|A method and system to reduce the nuisance alarm load in the clinical setting|
    CA2904053A1|2013-03-06|2014-09-12|Hospira, Inc.|Medical device communication method|
    US10476921B2|2013-06-12|2019-11-12|Carefusion 303, Inc.|System event notification|
    US20140372147A1|2013-06-13|2014-12-18|NaviNet, Inc.|Systems, methods, and environment for identification and processing of medical events|
    US9662436B2|2013-09-20|2017-05-30|Icu Medical, Inc.|Fail-safe drug infusion therapy system|
    US10521559B1|2013-10-18|2019-12-31|Advanced Health Communications, L.L.C.|Advanced healthcare information routing and delivery systems and methods of use and doing business|
    US10311972B2|2013-11-11|2019-06-04|Icu Medical, Inc.|Medical device system performance index|
    JP2016537175A|2013-11-19|2016-12-01|ホスピーラ インコーポレイテッド|Infusion pump automation system and method|
    US20150288645A1|2014-04-03|2015-10-08|Avid Technology, Inc.|Synchronized story-centric media distribution|
    AU2015253001A1|2014-04-30|2016-10-20|Icu Medical, Inc.|Patient care system with conditional alarm forwarding|
    US9724470B2|2014-06-16|2017-08-08|Icu Medical, Inc.|System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy|
    US9539383B2|2014-09-15|2017-01-10|Hospira, Inc.|System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein|
    US10911891B2|2014-12-18|2021-02-02|Drägerwerk AG & Co. KGaA|Alarm routing optimization strategies in targeted alarm system|
    US20170124507A1|2015-10-30|2017-05-04|Microsoft Technology Licensing, Llc|Workflow Management Using Third-Party Templates|
    CN106730196B|2016-12-12|2019-11-15|北京怡和嘉业医疗科技股份有限公司|A kind of alarm method, device and ventilator|
    US10861592B2|2018-07-17|2020-12-08|Icu Medical, Inc.|Reducing infusion pump network congestion by staggering updates|
    US20200027550A1|2018-07-17|2020-01-23|Icu Medical, Inc.|Maintaining clinical messaging during an internet outage|
    US20200035355A1|2018-07-26|2020-01-30|Icu Medical, Inc.|Drug library manager with customized worksheets|
    US11232410B2|2019-08-07|2022-01-25|Servicenow, Inc.|On-call scheduling and enhanced contact preference management|
    法律状态:
    2020-12-08| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|
    2020-12-08| B08F| Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]|Free format text: REFERENTE A 8A ANUIDADE. |
    2021-03-23| B08K| Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette]|Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2605 DE 08-12-2020 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013. |
    2021-12-07| B350| Update of information on the portal [chapter 15.35 patent gazette]|
    优先权:
    申请号 | 申请日 | 专利标题
    US201161429779P| true| 2011-01-05|2011-01-05|
    US61/429,779|2011-01-05|
    US201161532835P| true| 2011-09-09|2011-09-09|
    US61/532,835|2011-09-09|
    PCT/IB2011/055858|WO2012093307A1|2011-01-05|2011-12-21|System and method for distributing meaningful clinical alerts|
    [返回顶部]